Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/[e-mail] _Wed May 26 05:01:48 1993.msg

Internet Message Format | 1994-01-24 | 6KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA18314; Wed, 26 May 93 05:01:48 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA16871; Wed, 26 May 1993 05:23:09 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
    id AA16902; Tue, 25 May 1993 23:22:46 -0400
Received: from cider.west.ora.com by rock.west.ora.com (5.65c/Spike-2.1)
    id AA03134; Tue, 25 May 1993 20:22:42 -0700
Received: by cider.west.ora.com (5.65c/Spike-2.1)
    id AA03569; Tue, 25 May 1993 20:24:06 -0700
From: [e-mail] (Dale Dougherty)
Message-Id: <[e-mail]>
Date: Tue, 25 May 1993 20:24:05 -0700
In-Reply-To: Dave_Raggett <[e-mail]>
        "Re HMML?" (May 25,  5:59pm)
References: <[e-mail]>
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: Dave_Raggett <[e-mail]>
Subject: Re: Re HMML?
Cc: [e-mail]

On May 25,  5:59pm, Dave_Raggett wrote:

>My main objective is backwards compatibility with existing HTML. The change
>to the container model shouldn't effect such documents. Another objective is

I'd like to see some discussion about HMML being backwards
compatible with HTML.  I think it's a mistake to set that up as
a design objective.  It also raises questions about how WWW parsers
are going to work in the future.  I would prefer to see HTML as
a frozen thing; and HMML as the next generation.  HMML documents should
identify themselves using a document type declaration and parsers
should look for this information.

Once HMML becomes available, new documents should conform to
HMML, not HTML.  Support for HTML continues for already
existing documents.

Also, because HTML documents currently don't have to conform
to the HTML DTD, you have a lot more variety out there than
you expect.  It won't be easy for HMML to provide a useful
level of validation and grandfather the any-which-way-it-fits
HTML documents.

>to provide support for groupings of HTML documents that form on-line books,
>magazines, journals and conference proceedings etc. The idea here is to
>provide presentation independent markup as a basis for:
>
>    o   indexing based upon markup (title/author/subject, topics, ...)
>    o   familiar navigation model (tables of contents, indexes, ...)
>    o   printing related information (not just the current document)
>    o   importing books, etc into the web
>
>These extensions must be compatible with being able to parse HTML+ efficiently
>using modest programs (unlike HyTime!). I am currently analysing a wide range
>of paper material to see whether these documents can be adequately described
>using just a few new tags.

There are two things wrapped together in the above paragraphs.
First, you'd like HMML markup to be rich enough and stable
enough so that the WWW software can reliably produce the
listed behaviors.  The second is that these behaviors are
necessary to support more complex document models.  What
we really want are the behaviors, not necessarily the complex
document models.

As I see it, HMML should be designed for effective delivery
of documents in WWW; it should be a distribution format, not
a source, or authoring, format.   If you want to do the latter,
WWW would do best by taking the approach that it accept
any arbitrary SGML DTD.  That may happen,
one day, but it doesn't seem like the best approach today.
The main point is that I don't want to create and
manage information in HMML;  I want to use a full SGML DTD
that allows me to create and manage my information for multiple
uses, including printing or distribution in other systems.
I can filter from the richer, SGML DTD to HMML for distribution
on the Web.  Thus, HMML should be a useful subset of the
functionality required to deliver hypermedia documents over
networks.

Just to give an example, an authoring DTD might be concerned
with the semantic difference between COMMAND and FILENAME.  In
the HMML, we need not preserve that semantic distinction, and
we can call them the same thing.  I have seen one approach in
which all these elements were just classified as in-line
elements, and an attribute was used to preserve the original
element name.  Thus, COMMAND and FILENAME might both be distilled
into the element "INLINE", distinguishing it from things like
paragraphs, lists, and examples that are different types of
text blocks.

If we don't design HMML as a distribution format, the HMML DTD will grow and
grow to include new tags for new document types.
Look at the AAP DTD and you will see something that tries
to support lots of different document models.  The Docbook DTD has
a more limited scope but it is still reasonably large.  Short of
supporting any arbitrary DTD, we will find it difficult, I think,
to create an HMML DTD that serves complex document models you
describe.

HMML should still describe the logical components
of documents independent of a particular presentation.  However,
we should be concerned with presentation and distribution issues in
HMML, and define the appropriate mechanisms for doing it. In designing HMML,
we should largely concern ourselves with distilling the variety of different
document types into a simpler, limited format for distribution on the net
and presentation under a variety of different browsers.

--

Dale Dougherty
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472
[phone] (home office); 1-800-998-9938

UUCP:    uunet!ora!dale     Internet :   [e-mail]